Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/actions/node/action.yaml:
- Around line 5-7: The description for the node-version input is inconsistent
with the actual default; update the "description" string for the node-version
input so it matches the configured default value ('22.x') or change the
"default" to 'lts' if you intend to keep the original message—modify the
description line that currently reads "The node version to install (Default:
lts)" to reflect "Default: 22.x" (or set default to 'lts') so the node-version
input's description and the default: '22.x' stay aligned.

In `@composition/package.json`:
- Line 43: Update the composition package catalog entry for "@types/node" so it
permits Node 24 typings as well as 22; specifically replace the current catalog
pin ("@types/node": "catalog:") value with a version range that covers both
major versions (for example "^22.0.0 || ^24.0.0" or another appropriate
inclusive range) so TypeScript will resolve `@types/node` matching Node 24 when
running on Node 24, and ensure the change is made to the "@types/node"
dependency entry in composition/package.json.

In `@composition/src/schema-building/utils.ts`:
- Around line 600-602: When building schema nodes, ensure you clear
data.node.defaultValue when data.includeDefaultValue is false so previous
defaults don't leak; in the code handling data.includeDefaultValue (refer to the
data.includeDefaultValue check and the mutated data.node.defaultValue
assignment), add logic to remove or set data.node.defaultValue to undefined/null
in the else path (or before returning) so that when includeDefaultValue is false
any previously-set default is explicitly cleared.
- Around line 472-484: The current early-return path skips validation for single
directive instances; remove or change the short-circuit so that you always run
validateDirectives on the (possibly single) directive node(s). Specifically,
stop pushing directiveNodes directly and instead call
extractUniqueDirectiveNodes(directiveNodes) and then validateDirectives({ data,
directiveCoords: coords, directiveDefinitionData: directiveData, directiveNodes:
uniqueDirectiveNodes, parentDefinitionDataByTypeName }) for all cases (including
when length === 1); only push nodes into nodes after validation passes.

In `@composition/src/subgraph/utils.ts`:
- Line 21: The constructor/creator for InternalSubgraph is currently resetting
overriddenFieldNamesByParentTypeName to a new empty Map, which drops normalized
override metadata; instead copy or clone the existing override map from the
source subgraph into the new InternalSubgraph so override-aware logic keeps
working. Locate where InternalSubgraph is built (the place that sets
overriddenFieldNamesByParentTypeName) and replace the new Map() assignment with
a shallow copy/clone of the original map (preserving each Set<FieldName> per
TypeName) so callers that rely on overriddenFieldNamesByParentTypeName continue
to see the normalized override data.

In `@composition/src/v1/normalization/normalization-factory.ts`:
- Around line 733-745: handleComposeDirective currently assumes the first
argument is a string and calls startsWith on rawValue; add a guard in
handleComposeDirective (operating on the ComposeDirectiveNode and its argNode)
to verify the first argument is a string literal before using string
methods—e.g., check argNode.value.kind === 'StringValue' or typeof
argNode.value.value === 'string' and if that check fails push a composition
error (or reuse the existing directive error collection) and return early so
malformed non-string values (objects/booleans) do not cause a runtime exception
when evaluating rawValue.startsWith(LITERAL_AT).

In `@composition/src/v1/normalization/types/types.ts`:
- Around line 9-31: The ComposeDirectiveNode and ComposeDirectiveArgumentNode
types reference loc?: Location but Location isn't imported from 'graphql';
update the existing graphql import (the block that currently imports
ConstDirectiveNode, DocumentNode, InputValueDefinitionNode, Kind, NameNode,
StringValueNode, ValueNode) to also import the type Location so the loc property
resolves correctly for those types.

In `@composition/src/v1/warnings/warnings.ts`:
- Around line 211-238: The two warning message strings need copy fixes: in
composedOneOfDirectiveWarning update the concatenated message so "federated.
schema" becomes "federated schema" (remove the stray period and join sentences
cleanly) and in invalidRepeatedComposedDirectiveWarning remove the double space
in "defined  as" (make it "defined as") and tidy any surrounding
spacing/concatenation so the final Warning message reads smoothly; locate these
messages in the functions composedOneOfDirectiveWarning and
invalidRepeatedComposedDirectiveWarning and adjust the template strings
accordingly.

In `@composition/src/validation/validation.ts`:
- Around line 118-122: The current early return only checks that the named type
is an INPUT_OBJECT_TYPE_DEFINITION and that the argumentValue is an OBJECT, but
does not validate fields; replace the TODO by performing a deep comparison: when
parentData.kind === Kind.INPUT_OBJECT_TYPE_DEFINITION and argumentValue.kind ===
Kind.OBJECT, iterate the input object type definition (parentData) fields and
verify required fields are present, each provided field matches the field's
input type (recursively validate nested OBJECT/LIST/SCALAR values), and reject
unexpected fields not defined on parentData; reuse or call the existing
value-validation helper (or implement a recursive validateValueAgainstInputType
function) to validate nested values and ensure non-nullable constraints and
default behavior are enforced for symbols parentData, argumentValue, and Kind.
- Around line 108-110: The validator currently allows quoted strings for
enum-typed directive arguments by checking argumentValue.kind against
Kind.STRING; update the check in the block where parentData.kind ===
Kind.ENUM_TYPE_DEFINITION to reject Kind.STRING and only accept Kind.ENUM (i.e.,
remove or change the branch that treats Kind.STRING as valid) so
argumentValue.kind must equal Kind.ENUM to return true and everything else
returns false; adjust the logic around parentData.kind,
Kind.ENUM_TYPE_DEFINITION, and argumentValue.kind accordingly.

In `@composition/tests/v1/directives/compose-directive.test.ts`:
- Line 250: The placeholder test "that different core features can import the
same named directive if only one is composed" is empty and gives false coverage;
either implement real assertions that exercise the scenario or remove the test
until covered. Implementing: create two mock core feature modules that both
import a directive with the same name, compose only one of them via the
composeDirective/composeFeature helper used elsewhere in this suite, then assert
that importing the uncomposed feature does not produce a composed directive (or
produces a fallback) while the composed feature yields the composed directive;
use the existing test helpers and functions in compose-directive.test.ts (the
test block with that description) to locate where to add these assertions.
Ensure assertions check both feature-level import behavior and that only one
composed directive instance exists.

---

Outside diff comments:
In `@composition/src/normalization/normalization.ts`:
- Around line 1-34: The package removed the batchNormalize export from this
normalization entrypoint causing downstream imports (import { batchNormalize }
...) to break; restore a compatibility export by reintroducing batchNormalize
(or a deprecated shim that calls the new implementation) alongside
normalizeSubgraph and normalizeSubgraphFromString so composition's re-export
still exposes batchNormalize; locate where
normalizeSubgraph/normalizeSubgraphFromString are forwarded (functions
normalizeSubgraph, normalizeSubgraphFromString and the V1 implementations
normalizeSubgraphV1/normalizeSubgraphFromStringV1) and add an exported function
named batchNormalize that delegates to the appropriate V1 batchNormalize
implementation (or wraps it and emits a deprecation warning) to preserve
backwards compatibility.

In `@composition/src/v1/normalization/utils.ts`:
- Around line 467-512: The collection initializers are storing references to
mutable singleton DirectiveDefinitionData objects, causing mutations (e.g.,
version, isComposed, description) in normalization runs to leak across runs;
update initializeDirectiveDefinitionDatas() and FEDERATED_DIRECTIVE_DATAS to
store fresh copies instead of the imported *_DEFINITION_DATA singletons — for
each symbol like AUTHENTICATED_DEFINITION_DATA,
COMPOSE_DIRECTIVE_DEFINITION_DATA, etc., create a new DirectiveDefinitionData
instance or shallow-clone the object (so fields such as
version/isComposed/description are not shared) before inserting into the Map or
the FEDERATED_DIRECTIVE_DATAS array; ensure the same cloning approach is used
wherever those collections are built so normalization-factory.ts mutations no
longer affect subsequent runs.

---

Nitpick comments:
In `@composition/src/directive-definition-data/types/params.ts`:
- Around line 21-67: Change the exported object-shaped type aliases to exported
interfaces: replace the type declarations for
UpsertFederatedDirectiveDataParams, AddDirectiveArgumentDataByNodeParams,
DirectiveArgumentDataParams, DirectiveDefinitionDataParams, and
ExtractDirectiveArgumentDataParams with equivalent exported interfaces,
preserving all property names, optional modifiers (e.g. ?), exact property types
(Maps, Sets, unions like InputNodeKind | Kind.NULL), comments (e.g. the
commented configureDescription line), and exported status so consumers and
imports remain unchanged.

In `@composition/src/errors/types/types.ts`:
- Around line 3-6: Replace the exported type alias
InvalidRootTypeFieldEventsDirectiveData with an exported interface of the same
name (preserving the property names and types: definesDirectives: boolean and
invalidDirectiveNames: Array<DirectiveName>) so the object shape uses an
interface instead of a type; keep the export and the DirectiveName reference
unchanged.

In `@composition/src/index.ts`:
- Around line 3-5: The file contains duplicate barrel re-exports (e.g., the
export of './directive-definition-data/directive-definition-data' and
'./v1/constants/constants' appear more than once); remove the duplicate export
statements so each module is exported only once—locate the repeated export lines
for directive-definition-data and v1/constants in index.ts (also the repeated
block around lines 41-52) and delete the redundant entries, leaving a single
canonical export for each module.

In `@composition/src/normalization/types.ts`:
- Around line 36-63: Replace the object type aliases with interfaces for the
normalization result payloads: change the NormalizationSuccess type declaration
to an interface named NormalizationSuccess and do the same for
BatchNormalizationSuccess (the other alias referenced in the comment around
lines 72-84), keeping all property names and types identical; ensure exported
declarations remain exported and update any import/usage sites if they rely on
type-only constructs so the interface names are used consistently across
functions like any normalizer return types.

In `@composition/src/schema-building/types/params.ts`:
- Around line 13-75: Several exported object-shaped type aliases (e.g.,
IsTypeValidImplementationParams, GetRouterPersistedDirectiveNodesParams,
GetValidArgumentNodesParams, GetValidExecutableDirectiveArgumentNodesParams,
DirectiveDefinitionNodeFromDataParams, SanitizeDefaultValueParams,
RouterSchemaFieldNodeFromDataParams, RouterSchemaInputValueNodeFromDataParams,
RouterSchemaNodeFromDataParams, CompareAndValidateInputDefaultValuesParams)
should be converted to interfaces; change each "export type X = { ... }" to
"export interface X { ... }", preserving all property names and types (including
Maps, unions, optional fields like node? and description?), keep the same
exported identifiers so external usage/imports remain valid, and run TypeScript
type-check to confirm no downstream changes are required.

In `@composition/src/schema-building/types/types.ts`:
- Around line 181-186: Replace the exported type alias FederatedDirectivesData
with an exported interface of the same name and identical members
(deprecatedReason: string; directivesByName: Map<DirectiveName,
ConstDirectiveNode[]>; isDeprecated: boolean; tagDirectiveByName: Map<string,
ConstDirectiveNode>), so callers continue to work without behavior changes;
update any nearby JSDoc/comments if needed and ensure the exported symbol name
remains FederatedDirectivesData.

In `@composition/src/schema-building/utils.ts`:
- Around line 211-216: Replace the loose equality check between printed
default-value strings with a strict equality check: in the block that computes
existingDefaultValueString = print(existingData.defaultValue) and
incomingDefaultValueString = print(incomingData.defaultValue), change the
comparison from `==` to `===` so the early-return path in the function uses
strict equality (`existingDefaultValueString === incomingDefaultValueString`)
consistent with project guidelines.

In `@composition/src/subgraph/types/params.ts`:
- Around line 4-7: Replace the exported type alias
InternalSubgraphFromNormalizationParams with an exported interface of the same
name describing the same properties (normalization: NormalizationSuccess;
subgraphName: SubgraphName) so the object shape uses an interface instead of a
type alias; keep the same exported identifier and referenced types
(NormalizationSuccess, SubgraphName) so all callers remain compatible.

In `@composition/src/utils/params.ts`:
- Around line 16-19: Replace the type alias with an interface for the
object-shaped params: change the declaration of MergeSetValueMapParams to an
interface that declares source: Map<K, Set<V>> and target: Map<K, Set<V>> so it
follows the repo TypeScript guideline to use interfaces for object-shaped
contracts; keep the generic parameters <K, V> and the property names exactly as
in MergeSetValueMapParams to preserve usage compatibility.

In `@composition/src/v1/federation/federation-factory.ts`:
- Around line 1507-1549: Remove the large commented-out implementation inside
upsertPersistedDirectiveDefinitionData(): delete the dead code block (the
commented logic referencing potentialPersistedDirectiveDefinitionDataByName,
setMutualExecutableLocations, upsertInputValueData, setLongestDescription,
addIterableToSet, etc.) and either remove the empty function if it's unused or
replace it with a single-line TODO/issue-link comment explaining why
persisted-directive logic was retired; ensure no removed symbols are referenced
elsewhere or update callsites accordingly.

In `@composition/src/v1/normalization/batch-normalization/types/params.ts`:
- Around line 3-7: Replace the exported type alias HandleOverridesParams with an
exported interface of the same name and identical properties
(originalTypeNameByRenamedTypeName,
overriddenFieldNamesByParentTypeNameByTargetSubgraphName, subgraphName) so the
object contract is defined as an interface (preserve the Map/Set types and their
names) to match the repo style and enable easier future extension; update any
local references if needed but keep the exported symbol name unchanged.

In `@composition/src/validation/types/params.ts`:
- Around line 6-26: Replace the three exported object-shape type aliases
IsArgumentValueValidParams, ValidateCustomDirectiveParams, and
ValidateDirectivesParams with exported interfaces of the same names and
identical member signatures (argumentValue, parentDefinitionDataByTypeName,
typeNode for IsArgumentValueValidParams; argumentDataByName, directiveNode,
parentDefinitionDataByTypeName, requiredArgumentNames for
ValidateCustomDirectiveParams; data, directiveCoords, directiveDefinitionData,
directiveNodes, parentDefinitionDataByTypeName for ValidateDirectivesParams) so
the module follows the repo convention of using interfaces for parameter-bag
objects; keep all property types and export names unchanged.